1. Field of the Invention
The present specification relates to compression of data in communication systems, and in particular to compression of address data of a data stream communicated via a data communication system.
2. Description of the Related Art
A communication system can be seen as a facility that enables communications between two or more entities such as user equipment and/or other nodes associated with the communication system. The communication may comprise, for example, communication of voice, data, multimedia and so on.
A communication system typically operates in accordance with a given standard or specification which sets out what the various entities associated with the communication system are permitted to do and how that should be achieved. For example, the standard or specification may define if a circuit switched service and/or a packet switched service is provided. Communication protocols and/or parameters which shall be used for various functions on the system, such as routing, addressing and message formats, may also be defined. In other words, a specific set of “rules” on which the communication can be based on needs to be defined to enable communication by means of the system.
Routing of data packets between entities of a communication system is an important function of packet switched communication systems. In packet switched systems such as the Internet Protocol (IP) based networks a packet stream is routed via the various entities to the destination address based on address information contained in the headers of the packets of the stream.
The header information may be compressed. Header compression is considered as being one of the key techniques to improve spectrum efficiency and performance over wireless links or other links with limited bandwidth. These improvements are believed to be especially important for enabling wireless use of Internet.
In the existing header compression schemes the configuration involves a compressor and decompressor. The compressor receives uncompressed IP packets, divides them into separate streams based on IP address (source address, destination address, or both of these addresses) and possibly other header information (e.g. protocol type of upper layer, source and/or port number of upper layer). For each packet stream, the compressor maintains a compressor context and uses it to compress headers of this packet stream. The header-compressed packets are then communicated from the compressor to the decompressor. Usually, each compressed packet carries an indicator (e.g. context identification) to indicate to the decompressor which context has been used to generate this compressed packet. The decompressor also maintains a decompressor context for each packet stream. Various context synchronization mechanisms are usually used to ensure that a compressed packet can be successfully decompressed. When receiving a header compressed packet sent by the compressor, the decompressor decompresses the header using the correct decompressor context, reassembles the entire packet with the decompressed header, and then forwards the uncompressed packet to next entity, for example to a upper layer, commonly to a local upper layer, or to the next node on the packet path to its destination.
Conventional header compression schemes thus divide packets into packet streams and then compress each packet stream using a compression context established for that stream between a compressor and its peer decompressor. IP addresses are then used to classify a packet stream. Because of this IP packets carrying different IP addresses will be compressed using separate contexts.
A technique called “context replication” has been proposed in the Internet Engineering Task Force (IETF) to allow a new packet stream to be compressed using context of another existing packet stream. This may reduce the synchronization overhead for the new stream when header fields of packets belonging to the two (i.e. the existing and new) streams have the same or similar values. Otherwise, the uncompressed values of those header fields would need to be sent from the compressor to the decompressor to establish context for the new packet stream.
However, replication of contexts cannot be used for handling of IP addresses in all occasions. In particular, the proposal may only allow the context replication of IP addresses only in circumstances where the address data is exactly same between the new and existing packet streams. If there is even a small difference between the addresses, the compressor has to send the address uncompressed. The proposal does not even recognise a case where two packet streams carry substantially similar, but not exactly the same, IP addresses. Therefore the proposal does not enable optimisation that is based on exploitation of the similarity of IP addresses. In other words, the current context replication methods of robust header compression are not able to compress together IP addresses carried in packet streams with almost similar but not identical IP addresses.
Embodiments of the present invention aim to address one or several of the above problems.